Механизм электронной цифровой подписи (ЭЦП) возник как побочный эффект криптографии с открытым ключом. Поэтому, характерное для систем с открытым ключом разделение ключа на 2 части --- секретную и несекретную, позволяет реализовать возможность проверки подлинности без возможности подписать другой документ.

Итак, цифровая подпись это конечная цифровая последовательность, зависящая от самого сообщения или документа и от секретного ключа, известного только подписывающему субъекту, предназначенная для установления авторства. Так как цифровая подпись строится на базе криптосистемы с открытым ключом, то необходимо иметь пару ключей - секретный и открытый. Секретный ключ используется для формирования цифровой подписи, поэтому его нужно хранить в тайне. А открытый ключ используется для проверки соответствия подписи документу, поэтому он должен быть опубликован, например, в общедоступном каталоге.

Предположим, что абонент A уже сформировал свою пару секретного и открытого ключей и на их основе построил функции D_KA(x) и E_KA(x). Причем для любого x должно выполнятся равенство E_KA(D_KA(x)) = x. Функцию D_KA(x) будем называть функцией подписи сообщения x, а функцию E_KA(x) функцией проверки подписи для сообщения x. В дальнейшем будем отождествлять функции D_KA(x) и E_KA(x) с секретным и открытым ключами пользователя A соответственно. Надо заметить, что функции D_KA(x) и E_KA(x) связаны (так как связаны секретный и открытый ключи), однако по опубликованной функции E_KA(x) вычислительно невозможно восстановить функцию D_KA(x).

Рассмотрим схему взаимодействия отправителя (A) и получателя (B), которая позволяет B проверить подлинность передаваемого сообщения.

Рассмотренный протокол взаимодействия имеет следующий недостаток: так как функция E_KA(x) - опубликована, то злоумышленник C может для любого z вычислить E_KA(z) и предать в канал связи пару (E_KA(z),z). Несложно видеть, что в этом случае z, будет подписью для E_KA(z). Для предотвращения такой возможности пользователи должны подписывать не сами сообщения, а их хэши, то есть значения хэш-функции от сообщения.

Напомним определение хэш-функции.

Где M - множество векторов фиксированной длины, а X - вектора произвольной длины. Пара (x, x') из X² такая, что x неравно x' и h(x) = h(x') называется коллизией хэш-функции h.

Помимо устранения рассмотренной выше возможности создания подписи без знания секретного ключа, использование хэш-функции решает еще одну проблему: дело в том, что функции E_KA(x) и D_KA(x) оперируют с блоками данных фиксированного размера, а размер сообщения может превышать этот размер. Без использования хэш-функции подписывать сообщение x пришлось бы следующим образом:

x = (x₁,..,x_k) \to ( (x₁,D_KA(x₁)),.., (x_k,D_KA(x_k))).

Где x₁,..,x_k - вектора фиксированной длины, совпадающей с длиной входа функций E_KA(x) и D_KA(x). Подобная подпись обладает следующими недостатками:

В этом протоколе возможность подделки подписи может быть основана на нахождении коллизии хэш-функции, то есть по известному значению h(x) найти x' такой, что h(x) = h(x'). Для предотвращения этой возможности нельзя использовать непроверенные функции. Как правило, стойкие к коллизиям хэш-функции описаны в государственном стандарте. В Российской Федерации этот стандарт носит название ГОСТ Р 34.11-94, в США - описывается документами FIPS 180-1 и FIPS 180-2, а в Евросоюзе рекомендуется использование стандарта Whirlpool. Отечественный стандарт хэширования был принят в 1994 году и с тех пор не изменялся, размер хэш-блока для него составляет 256 бит. В США изначально действовал стандарт SHS (secure hash standard), где размер хэш-блока был равен 160 бит. Однако в 2002 году стандарт был пересмотрен: прежний остался действовать и получил обозначение SHA-1, но к нему были добавлены три новых алгоритма, вырабатывающие хэш-блоки размером 256,384 и 512 бит, названные SHA-256/384/512 соответственно.

Однако рассмотренные выше протоколы не учитывают один факт: а как пользователю B убедится, что открытый ключ E_KA принадлежит отправителю A. Рассмотрим подробнее проблему доверия пользователя B открытому ключу отправителя A. При использовании цифровой подписи A и B нужно защищать только свои личные секретные ключи. А открытые ключи им нужно использовать совместно. Хранить их в секрете нет необходимости, нужна лишь возможность идентифицировать открытый ключ другой стороны. Поэтому для применения цифровой подписи критическое значение имеет доверие к соответствию между известным субъектом и его открытым ключом. B может доверять открытому ключу A, если A передал ему ключ безопасным способом. Но безопасность передачи обеспечивается только защищенными средствами связи. Более вероятно, что B получил открытый ключ A с помощью незащищенного средства связи (например, из общего каталога), поэтому нужен механизм, который может обеспечить B уверенность в том, что имеющийся у него открытый ключ действительно принадлежит A, а не кому-либо другому.
Один их таких механизмов основан на сертификатах (certificate), выдаваемых центром сертификации (certification authority). Сертификаты обеспечивают механизм надежной связи между открытым ключом и субъектом, которому принадлежит соответствующий личный ключ. Сертификат это цифровой документ, который содержит открытый ключ субъекта (subject public key) и подписан электронной цифровой подписью его издателя (issuer). Сертификат также содержит сведения о владельце открытого ключа, например, информацию, которая его дополнительно идентифицирует. Таким образом, выдавая сертификат, издатель удостоверяет подлинность связи между открытым ключом субъекта и информацией, его идентифицирующей. В настоящее время наиболее часто используются сертификаты на основе стандарта Международного союза телекоммуникаций ITU-T X.509 версии 3 и рекомендаций IETF (Internet Engineering Task Force) RFC 2459. Например, формат сертификата X.509 принят в протоколах S/MIME, IP Security, а также SSL/TLS и SET. Кроме того, это базовая технология, используемая в инфраструктуре открытых ключей операционной системы Windows 2000. Однако это не единственный вид сертификатов. Например, система защиты сообщений электронной почты PGP (Pretty Good Privacy) использует свою специфическую форму сертификатов.

Центр сертификации (ЦС) --- это служба, которая выдает сертификаты.

Центр сертификации является гарантом связи между открытым ключом субъекта и содержащейся в сертификате информацией по идентификации этого субъекта. Различные ЦС устанавливают и гарантируют эту связь различными способами, поэтому прежде чем доверять сертификатам того или иного ЦС, следует ознакомиться с его политикой и регламентом.

Когда B получает подписанное сообщение, у него возникает важный вопрос можно ли этой подписи доверять? Иными словами действительно ли эта подпись принадлежит отправителю сообщения? B может проверить целостность подписи с помощью известного ему открытого ключа отправителя и криптографических алгоритмов. Однако при этом B должен быть уверен в том, что использованный им для проверки открытый ключ действительно принадлежит тому субъекту, именем которого подписано сообщение. Если у B нет прямого доказательства, что открытый ключ принадлежит A, то ему надо получить хотя бы достаточно веское подтверждение этого. Если B сможет найти сертификат открытого ключа A, выданный тем центром сертификации, которому он доверяет, то он получит убедительное подтверждение того, что открытый ключ A действительно принадлежит A. Итак, у B появится веское основание полагать, что открытый ключ принадлежит именно A, если он найдет сертификат, который:

Если B найдет такой сертификат открытого ключа A, то он сможет проверить подлинность этого сертификата с помощью открытого ключа центра сертификации. Однако теперь у B возникает следующий вопрос . Как убедиться в том, что этот открытый ключ действительно принадлежит данному центру сертификации? B нужно найти сертификат, удостоверяющий подлинность этого центра сертификации. Таким образом в процессе проверки сертификата B продвигается по цепочке сертификатов (certification path). В конце цепочки сертификатов, ведущей от сертификата открытого ключа A через ряд центров сертификации, находится сертификат, выданный тем ЦС, которому B полностью доверяет. Такой сертификат называется доверенным корневым сертификатом (trusted root certificate), поскольку он образует в иерархии связей <открытые ключи --- личность> корень (самый верхний узел), который B считает надежным. Если B явно решит доверять этому доверенному корневому сертификату, то он неявно будет доверять всем сертификатам, выданным доверенным корневым сертификатом и всеми сертифицированными им ЦС. Набор доверенных корневых сертификатов, которым B доверяет явно это единственная информация, которую B должен получить надежным способом. На этом наборе сертификатов базируется его система доверия и обоснование надежности инфраструктуры открытых ключей.